In computing systems, an interrupt is a signal generated by hardware or software indicating an event that needs immediate attention from the processor (i.e., requiring an interruption of the current thread the processor is executing). The processor responds by suspending its current execution thread, saving the state (so that it can re-start execution where it left off), and executing a function referred to as an interrupt handler to service the event. The interruption is temporary; after the interrupt handler completes, the processor resumes execution of the thread.
Hardware interrupts are used by devices to communicate that they require attention from the operating system and are implemented using electronic alerting signals that are sent to the processor. For example, a keyboard or mouse may trigger an interrupt request in response to a user pressing a key on the keyboard or moving the mouse, respectively. In response, the processor is interrupted to read the keystroke or mouse position. The act of initiating a hardware interrupt is referred to as an interrupt request. The number of hardware interrupts is limited by the number of interrupt request (IRQ) lines to the processor, but there may be hundreds of different software interrupts.
Current multi-processor and/or multi-core systems rely on Advanced Programmable Interrupt Controllers (APICs) to process interrupts directed to different processor/cores. The APIC may be a split architecture design, with a local component (LAPIC) usually integrated into the processors/cores, and an optional input/output (I/O)-APIC on a system bus.
In the IO-APIC, the Interrupt Distribution is either based on a fixed destination or a redirectable destination. Often, embedded systems which cannot use Symmetric Multiprocessing opt to use a fixed destination mode. In such cases, the destination of an interrupt has to be reprogrammed frequently for various reasons. The affinity of interrupts towards certain core(s)/processor(s) in fixed destination mode needs to be reconfigured depending on the use case being executed. Reconfiguring interrupts one at a time becomes an overhead and this latency due to reprogramming can impact system performance.